Pipeline, March/April 1995, vol.6, no.2
Copyright © 1995 Silicon Graphics
IRIX dynamically loadable kernel modules were introduced with the release of IRIX 5.0. The necessary steps to create and load dynamic loadable kernel modules is documented in the mload(4), ml(1M), and lboot(1M) manual pages and the IRIX Device Driver Programming Guide for IRIX 5.0 and later releases. This article will only focus on the following issues related to dynamic loadable kernel modules:
The term module refers to any of the following in this article: a character or block device driver, streams device driver, streams module, library module, and kernel debug module (kernel debug modules are only supported in IRIX 5.2 and above). Modules are either provided with IRIX or can be developed by users.
What are Dynamic Loadable Kernel Modules
Until IRIX 5.0, the only way to incorporate a module into the kernel was to add a module to the disk copy of the kernel and run lboot(1M) to generate a new kernel. After running lboot, the system had to be rebooted to use the new kernel.
IRIX 5.0 introduced a mechanism to incorporate modules into the kernel currently running on the system without using lboot and rebooting the system. This mechanism is known as a dynamic loadable kernel module. The basic idea is that a compiled object module (.o file) is attached to the running kernel using the command ml.
Which Versions of IRIX Support Dynamic Loadable Kernel Modules
The easiest way to determine if dynamic kernel loadable modules are supported is by executing the ml command. If it returns a message similar to "Module loader not enabled", then it is not possible to use the dynamic load- able kernel module feature. This feature is supported in IRIX 5.x, and IRIX 6.0.1. It is not supported in IRIX 6.0.
Which IRIX Modules are Dynamic Loadable Kernel Modules
IRIX modules are located in the directory /var/sysgen/boot and are in object file format (.o files). The associated master file for each module is located in /var/sysgen/master.d. If field 1, the FLAG field, of the associated master file has a d entry, it is a dynamic loadable kernel module.
Determining the state of a dynamic loadable kernel module (registered, loaded, registered and loaded, or none of the above) can be accomplished with the command:
% /sbin/ml list
When is it Appropriate to Use Dynamic Loadable Kernel Modules
Now that this feature is available in IRIX 5.x and IRIX 6.0.1, any time a module needs to be added to a kernel, it is always appropriate to use dynamic loadable kernel modules. Some of the major benefits include:
Here is how registering works: The first time a process opens the device associated with the kernel module, the kernel will load the module. The steps performed during the load are described in the "Performance related issues" section below. If no processes need access to the module, it can then be manually unloaded and or unregistered from the running kernel (refer to the ml(1M) manual page for details). In IRIX 5.3, a module can be automatically unloaded from the system if it has not been used for x amount of time. This is described in the mload(4) manual page.
Performance Related Issues
One of the requirements when using dynamic loadable kernel modules is the use of the -Wc,-jalr compile time flag. Using this flag tells the code generator to produce jalr instructions rather than jal instructions (refer to the Module Configuration section of the mload(4) manual page). A jal instruction has a 26 bit target address, so if a module is loaded into K2SEG, for example, it could not call a kernel routine in K0SEG. The jalr instruction uses a 32 bit target address. The time it takes to execute a jalr instruction is no different than the time it takes to execute a jal instruction. However, the jalr instruction requires that the address that it "jumps" to be determined at runtime, as opposed to the jal "jump" address which is determined at compile time. This usually requires one or two extra instructions each time the module makes a function call.
On SGI hardware that supports branch prediction (e.g., R8000 processors) jalr is not as efficient as using jal in branch prediction hardware.
If the dynamic loadable kernel module is only registered and not loaded, the first time a process opens the device associated with the module, a number of actions must be performed:
Refer to the IRIX Device Driver Programming Guide for IRIX 5.0 and later releases for more detailed information related to the register and load sequence.
How to Tell if a Dynamic Loadable Kernel Module Functions Properly
The section labeled CAVEATS at the end of the mload(4) manual page contains a list of possible reasons loading a dynamic loadable kernel module will fail. The file /usr/include/sys/mload.h also contains a list of errno(3C) numbers that apply when ml fails. In general, if ml does not report an error, the module will function as if it was loaded into the kernel with the traditional lboot utility.
Debugging a Dynamic Loadable Kernel Module
The kernel symbolic debugger, symmon(1M), can be used to debug dynamic loadable kernel modules just as it can be used to debug static kernel modules. An additional command, msyms, was added to symmon to list the symbols for a particular dynamic loadable kernel module. The msyms command also provides other useful information on all dynamic loadable kernel modules configured in the system including the current state, id number, module type, reference count, major number(s), and module function entry point addresses.